Summary

Closes part of #856 (the tracked "next lever" — the per-iteration $Runtime::CheckCancellation() call).

Every loop backedge emitted an unconditional call $Runtime.CheckCancellation(). RyuJIT won't inline CheckCancellation (it contains newobj+throw), so that bare call sat in every loop body as a per-iteration optimization barrier — measured at ~half the runtime of a tight numeric loop.

This inlines the field test on the hot path and only calls the throwing helper on the cold cancel path:

volatile. ldsfld bool $Runtime::_cancelRequested
brfalse   <loop body>                       // hot path: skip straight past
call      $Runtime::CheckCancellation()      // cold: only when cancelling

The volatile. prefix is mandatory for correctness: _cancelRequested is loop-invariant, so a plain ldsfld could be hoisted out of the loop by RyuJIT's LICM — reading the flag once and never re-checking, silently reintroducing the #74 async-hang. The volatile read forbids the hoist and measured at zero cost. Only the loop-backedge emitter changed; the cold throw stays in the helper, and the dynamic-invocation recursion guard (EmitStackGuard) is left as a plain call (not per-iteration-hot; directly-compiled calls bypass it).

Results (branch vs main vs Node)

The win scales with the loop's arithmetic fraction (biggest on pure-numeric loops, smaller where array ops dominate). No regression on other workloads.

Correctness — verified directly

• Test262 runner: compile-mode cooperative cancellation #74 cancellation preserved: a compiled while(true) loop ran 1s, then unwound with OperationCanceledException the instant _cancelRequested was tripped via reflection (the exact test-harness path). vm-timeout tests pass; Test262 Timeout=0.
• dotnet test: 13994 pass. The Test262 baseline-drift failures (2 interpreted / 4 compiled, all in Array.isArray/Math/Proxy families) reproduce identically on main — pre-existing stale baseline, not from this change (verified by stash + rebuild + re-run). The 6 compiled-mode unit failures pass in isolation (parallel DLL-build contention flakiness).
• SharpTS.TypeScriptConformance: green (codegen change can't affect the type-checker).

Follow-ups (not in this PR)

• Throttle (per-loop counter, check every N) would reach the ~2.27× ceiling on pure-numeric loops, at the cost of a counter local.
• Pure-numeric loops remain ~3× off Node due to separate levers: non-inlined user-function calls + boxed top-level vars.